| Oracle® Retail Merchandising Foundation Cloud Service Operations Guide Volume 2 - Message Publication and Subscription Designs Release 19.2.000 F36505-04 |
|
 Previous |
 Next |
| Oracle® Retail Merchandising Foundation Cloud Service Operations Guide Volume 2 - Message Publication and Subscription Designs Release 19.2.000 F36505-04 |
|
Previous |
Next |
This chapter gives an overview about the SOAP Web service implementation used in Merchandising.
The Simple Object Access Protocol (SOAP) is a general-purpose messaging protocol that is the de facto standard for web services messaging and interaction through the Oracle Retail Integration Cloud Service (RICS) Retail Service Backbone (RSB), which provides monitoring for the SOAP services used by Merchandising. The basic unit of interaction between a SOAP client and a SOAP-enabled service is a message. A SOAP message is basically an XML document that consists of two parts:
An optional header providing information on authentication, encoding of data, or how a recipient of a SOAP message should process the message.
The body that contains the message. These messages are defined using the WSDL specification.
An envelope can enclose any number of optional headers. The following diagram shows the high-level architecture of SOAP web service implementation with respect to Merchandising:
The services should not be used during the restricted batch window.
A Retail Application will package its SOAP services as part of the application's Enterprise Archive (EAR) file. Installation of the SOAP web services is therefore done by default as part of the application install. Refer to Oracle Retail Service Backbone Implementation Guide for more details.
Services are secured using a standard policy-based security model supported by WebLogic and OSB.
For more details, refer to the Oracle Retail Service Backbone Security Guide.
Example response payload in case of service success is depicted below:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns1:createDetailXAllocDescResponse xmlns:ns1="http://www.oracle.com/retail/rms/integration/services/AllocationService/v1"
xmlns:ns3="http://www.oracle.com/retail/integration/base/bo/InvocationSuccess/v1"
xmlns:ns2="http://www.oracle.com/retail/integration/base/bo/XAllocDesc/v1"
xmlns:ns4="http://www.oracle.com/retail/integration/base/bo/XAllocColRef/v1"
xmlns:ns5="http://www.oracle.com/retail/integration/base/bo/XAllocRef/v1">
<ns3:InvocationSuccess>
<ns3:success_message>createDetailXAllocDesc service call was successful.</ns3:success_message>
</ns3:InvocationSuccess>
</ns1:createDetailXAllocDescResponse>
</S:Body>
</S:Envelope>
Example response payload in case of service error is depicted below:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns0:Fault xmlns:ns0="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://www.w3.org/2003/05/soap-envelope">
<faultcode>ns0:Server</faultcode>
<faultstring>Invalid Item. 1003500087</faultstring>
<detail>
<ns0:IllegalStateWSFaultException xmlns:ns0="http://www.oracle.com/retail/integration/services/exception/v1">
<ns0:shortErrorMessage>Invalid Item. 1003500087</ns0:shortErrorMessage>
<ns0:errorDescription>
com.oracle.retail.integration.services.exception…
</ns0:errorDescription>
<ns0:BusinessProblemDetail>
<ns0:problemDescription>Invalid Item. 1003500087</ns0:problemDescription>
</ns0:BusinessProblemDetail>
</ns0:IllegalStateWSFaultException>
</detail>
</ns0:Fault>
</S:Body>
</S:Envelope>
To access the Merchandising SOAP web services WSDL file:
https://<hostname>/<end-point>
The end point information is in the descriptions of each of the provider services later in this chapter.
The following diagram shows the Web Service API process flow for Merchandising as a Service Provider:
This section gives an overview about the SOAP Web service provider implementation API designs used in the Merchandising environment and various functional attributes used in the APIs.
|
Note: The following service provider implementation API designs are intended only to give a high-level overview of the APIs available. The implementation of these services, along with the associated Web Service Definition Language (WSDL), may be used to get a full understanding of the data requirements, validation rules, persistence rules, and return values associated with the service. |
To provide visibility to the background processing that's occurring, services write to the JOB_AUDIT_LOGS table in the database. Reports can be built based on this to provide visibility to what is happening in the background. Additionally, to assist users and developers in troubleshooting any error that may arise, the payload that was processed is also stored in the JOB_AUDIT_PAYLOAD table in the database.
Once the nightly batch run has started, web service execution will be halted, and users will receive a warning message that the nightly batch run has commenced.
This section gives an overview about the SOAP Web service provider implementation API designs used in the Merchandising environment and various functional attributes used in the APIs.
|
Note: The following service provider implementation API designs are intended only to give a high level overview of the APIs available.The implementation of these services, along with the associated Web Service Definition Language (WSDL), may be used to get a full understanding of the data requirements, validation rules, persistence rules, and return values associated with the service. |
This service allows an external application to create, update, and delete allocations within Merchandising based on warehouse inventory or to cross-dock a purchase order.
This service uses the same logic as is supported in the Allocation Subscription RIB API. For information about this functionality, see Allocation Subscription API in the "RIB Subscription Designs" chapter of this document.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| create | XAllocDesc | InvocationSuccess | XAllocDesc.xsd |
| createDetail | XAllocDesc | InvocationSuccess | XAllocDesc.xsd |
| modifyHeader | XAllocDesc | InvocationSuccess | XAllocDesc.xsd |
| modifyDetail | XAllocDesc | InvocationSuccess | XAllocDesc.xsd |
| delete | XAllocColRef | InvocationSuccess | XAllocRef.xsd
XAllocColRef.xsd |
| deleteDetail | XAllocColRef | InvocationSuccess | XAllocRef.xsd
XAllocColRef.xsd |
This service supports updating weighted average cost from an external system for one or more item/locations combinations. It also creates a tran data record posting with tran code 70 for the difference in cost, based on owned inventory at the location at the time the cost change is applied.
The web service will be called with the following details:
Item
Location
Location Type
New average cost (must be greater than 0)
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| modifyAvgCost | ItLocAgCstColDesc | InvocationSuccess | ItLocAgCstDesc.xsd ItLocAgCstColDesc.xsd |
This service is exposed to allow an external application to create cost changes in Merchandising. It takes a collection of cost changes and will return success and failure through the service response object.
This service uses the same logic as is supported in the Cost Change Subscription RIB API. For information about this functionality, see Cost Change Subscription in the "RIB Subscription Designs" section of this document.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| create | XCostChgColDesc | InvocationSuccess | XCostChgDesc.xsd
XCostChgColDesc.xsd |
/rms-CustomerCreditCheck-AppServiceDecorator/ProxyService/CustomerCreditCheckAppServiceProxy?wsdl
This API provides a way for an external source, usually a financials system, to update the credit status for a franchise customer in Merchandising. This status is used when determining whether a franchisee order can be approved. Valid values are Y (credit is good) and N (credit issues). For each collection of customer and customer group passed into the API, the credit flag will be updated with the value indicated in the service call.
Merchandising returns failure status as part of the response object in the web service call if credit flag is not updated due to validation errors.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| updateCustCredit | CustCreditChkCol | InvocationSuccess | CustCreditChkDesc.xsd
CustCreditChkCol.xsd |
This service is used to process Customer Order Fulfillment requests from an order management system (OMS). Merchandising supports two integration methods for processing Customer Order Fulfillment messages from OMS - either through RIB or web service. At implementation time, you should decide on either one or the other integration method, but not both. The same core logic is used to validate and persist customer orders.
In a web service implementation, the web service is used to create or cancel a customer order in Merchandising. This service
Accepts a collection of fulfillment orders as input. If one order fails, the entire service call fails and no orders will be created.
Returns Failure status as part of the response object in the web service call if customer orders are not created due to validation errors.
Returns Success status and a confirmation message as part of the response object of type
X if customer orders are not created due to lack of inventory
P if customer orders are partially created due to insufficient inventory
C if customer orders are completely created, when sufficient inventory is available
In a web service implementation, confirmation messages will be sent in a collection as part of the response object.
This is the web service version of the same logic as is supported in the RIB version of the API. See Customer Order Fulfillment Subscription API in the "RIB Subscription Designs" chapter for more information.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| create | FulfilOrdColDesc | FulfilOrdCfmCol | FulfilOrdDesc.xsd
FulfilOrdColDesc.xsd |
| cancel | FulfilOrdColRef | InvocationSuccess | FulfilOrdRef.xsd
FulfilOrdColRef.xsd |
/rms-CustOrdSubstitute-AppServiceDecorator/ProxyService/CustOrdSubstituteAppServiceProxy?wsdl
When a store is picking inventory to fulfill a customer order, if the inventory of the item ordered does not meet quality standards or is unavailable, and the order indicates that substitutions are allowed for that item, the store may choose to fulfill the order with a substitute item. If that occurs, SIM has the ability to substitute items on the customer order with another predefined substitute item. In such cases, SIM notifies OMS via the Stock Order Status message that an alternative item has been pushed into the order.
Based on the notification from SIM, OMS updates the customer order and notifies Merchandising with the same details received from SIM using this API. Merchandising will then update the inventory and customer order details - removing the reservation for the original item and adding a reservation for the new item. Merchandising will also update the cancelled quantity for the original item on the order and add the details for the substituted item, with a cross reference to the original item.
Substitution logic holds good only for the customer orders fulfilled from stores.
Catchweight, Transformable, Consignment, Concession and Deposit container items are not supported for customer order item substitution.
The quantities are always in Standard UOM.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| create | CustOrdSubColDesc | InvocationSuccess | CustOrdSubDesc.xsd
CustOrdSubColDesc.xsd |
/rms-DiffManagement-AppServiceDecorator/ProxyService/DiffManagementAppServiceProxy?wsdl
This service supports the following functions
Creating new differentiator (diff) IDs
Updating existing diff IDs
Deleting existing diff IDs
Creating diff group header and details
Updating existing diff group headers and details
Deleting existing diff group headers and details
This API uses the same logic that is used for managing diffs through the Diff Subscription RIB API. See Diff Group Subscription API and Differentiator Subscription API in the "RIB Subscription Designs" chapter of this document for more details.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| createDiffId | XDiffIDColDesc | InvocationSuccess | XDiffIDDesc.xsd
XDiffIDColDesc.xsd |
| modifyDiffId | XDiffIDColDesc | InvocationSuccess | XDiffIDDesc.xsd
XDiffIDColDesc.xsd |
| deleteDiffId | XDiffIDColRef | InvocationSuccess | XDiffIDRef.xsd
XDiffIDColRef.xsd |
| createDiffGrp
createDiffGrpDtl |
XDiffGrpColDesc | InvocationSuccess | XDiffGrpDesc.xsd
XDiffGrpColDesc.xsd |
| modifyDiffGrp
modifyDiffGrpDtl |
XDiffGrpColDesc | InvocationSuccess | XDiffGrpDesc.xsd
XDiffGrpColDesc.xsd |
| deleteDiffGrp
deleteDiffGrpDtl |
XDiffGrpColRef | InvocationSuccess | XDiffGrpRef.xsd
XDiffGrpColRef.xsd |
/rms-InventoryBackOrder-AppServiceDecorator/ProxyService/InventoryBackOrderAppServiceProxy?wsdl
Retailers selling through ecommerce channels often take customer orders even if inventory is not available with the expectation of future inventory being available to fill the order. If an order is captured against future inventory by the Order Management System (OMS), then a backorder message is sent to Merchandising through this service.
This web service will update the backorder quantity in Merchandising - increasing when the backorder is taken and decreasing when the backorder is released for fulfillment or cancellation.
Backorders can be taken against both stores and warehouses. OMS will determine which location will be back ordered.
An item does not need to have an open purchase order in order to increase backorder quantity.
Catchweight, Transformable, Consignment, Concession and Deposit container items are not supported for backorder requests.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| create | InvBackOrdColDesc | InvocationSuccess | InvBackOrdDesc.xsd
InvBackOrdColDesc.xsd |
/rms-InventoryDetail-AppServiceDecorator/ProxyService/InventoryDetailAppServiceProxy?wsdl
This real-time inventory availability lookup facility can be used by external systems, such as an on-line order capture system (OOC) or order management system (OMS), to retrieve item/location available inventory based on Merchandising's current view of inventory. Merchandising will provide this information for any warehouse or store which is valid for customer order sourcing/fulfillment.
Available inventory is calculated as
Stock on Hand - (transfer reserved + customer reserved + RTV + non-sellable)
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
Catchweight, transformable, consignment, concession and deposit container items are not supported in this API.
This inventory detail lookup is only for customer orderable inventory - sellable items at customer order locations. If a physical warehouse and channel are passed into the API, then only the inventory for the customer orderable virtual warehouses for that physical warehouse/channel are returned.
If the inventory lookup is for a pack item at store, the pack inventory is estimated based on the maximum number of complete packs which can be created by using the available inventory of its components.
Merchandising does not use the Search Area information in this service. It will only lookup inventory for the specific locations included in the input object.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| lookup | InvAvailCriVo | InvAvailColDesc | InvAvailCriVo.xsd
InvAvailDesc.xsd InvAvailColDesc.xsd |
/rms-ItemManagement-AppServiceDecorator/ProxyService/ItemManagementAppServiceProxy?wsdl
The Item Management service allows an external systems to request pre-issued item numbers, as well as create, modify and delete various aspects of an item.
The Item Number Reservation web service allows external systems such as Oracle Retail Assortment Planning (AP) to reserve item numbers in Merchandising. This web service contains the following details:
| Column Name | Notes |
|---|---|
| Item Number Type | Required. Indicates the type of items numbers being requested. Valid options are:
|
| Quantity | Indicates the number of item numbers being requested. Required. |
| Days Until Expiry | Indicates how long the calling solution wants Merchandising to retain the reservation. After this many days, the reservation will be released allowing these numbers to be used for other purposes. This is required and must be a value greater than 0. |
The requested item numbers are sent back to the calling solution as a response. This operation is only available as part of the web service.
The operations supported in this service for creating and managing items are as follows:
Creating and modifying items
Creating, modifying, and removing item suppliers
Creating, modifying, and removing item supplier sourcing country
Creating, modifying, and removing item supplier country dimensions
Creating, modifying, and removing item UDA combinations
Creating and removing item reclassifications
This service uses the same logic to manage these operations as is used in the Item Subscription RIB API. For information on this functionality, see Item Subscription API in the "RIB Subscription Designs" chapter of this document.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| reserveItemNumber | ItemNumCriVo | ItemNumColDesc | ItemNumCriVo.xsd
ItemNumDesc.xsd ItemNumColDesc.xsd |
| createItem | XItemColDesc | InvocationSuccess | XItemDesc.xsd
XItemColDesc.xsd |
| createSupplier | XItemColDesc | InvocationSuccess | XItemDesc.xsd
XItemColDesc.xsd |
| createSupplierCountry | XItemColDesc | InvocationSuccess | XItemDesc.xsd
XItemColDesc.xsd |
| createSupplierCountryDim | XItemColDesc | InvocationSuccess | XItemDesc.xsd
XItemColDesc.xsd |
| createUDA | XItemColDesc | InvocationSuccess | XItemDesc.xsd
XItemColDesc.xsd |
| modifyItem | XItemColDesc | InvocationSuccess | XItemDesc.xsd
XItemColDesc.xsd |
| modifySupplier | XItemColDesc | InvocationSuccess | XItemDesc.xsd
XItemColDesc.xsd |
| modifySupplierCountry | XItemColDesc | InvocationSuccess | XItemDesc.xsd
XItemColDesc.xsd |
| modifySupplierCountryDim | XItemColDesc | InvocationSuccess | XItemDesc.xsd
XItemColDesc.xsd |
| modifyUDA | XItemColDesc | InvocationSuccess | XItemDesc.xsd
XItemColDesc.xsd |
| deleteSupplier | XItemColRef | InvocationSuccess | XItemRef.xsd
XItemColRef.xsd |
| deleteSupplierCountry | XItemColRef | InvocationSuccess | XItemRef.xsd
XItemColRef.xsd |
| deleteSupplierCountryDim | XItemColRef | InvocationSuccess | XItemRef.xsd
XItemColRef.xsd |
| deleteUDA | XItemColRef | InvocationSuccess | XItemRef.xsd
XItemColRef.xsd |
| createItemReclass | XItemRclsDesc | InvocationSuccess | XItemRclsDesc.xsd |
| createItemReclassDetail | XItemRclsDesc | InvocationSuccess | XItemRclsDesc.xsd |
| deleteItemReclass | XItemRclsRef | InvocationSuccess | XItemRclsRef.xsd |
| deleteItemReclassDetail | XItemRclsRef | InvocationSuccess | XItemRclsRef.xsd |
The Pay Term Service is used by Oracle Retail Financial Integration (RFI) for integration of payment terms with PeopleSoft Financials, and can also be used by an external financial systems to send new and updated payment terms information to Merchandising. The operations supported in this service are:
Create: Create payment terms and details
Create Detail: Add details to an existing payment term
Update Header: Modify existing payment term header information
"Update or Update Details: Modify existing details for a payment term
The operations supported by this service involve an external system sending Merchandising details to create or update payment terms. In the response back, the terms keys are returned on success. The create and update options for this service use the same logic as is supported in the Payment Terms Subscription RIB API.
For information about this functionality, see Payment Terms Subscription API in the "RIB Subscription Designs" chapter of this document.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| create | PayTermDesc | PayTermRef | PayTermDesc.xsdPayTermRef.xsd |
| createDetail | PayTermDesc | PayTermRef | PayTermDesc.xsdPayTermRef.xsd |
| update | PayTermDesc | PayTermDesc | PayTermDesc.xsd |
| updateHeader | PayTermDesc | PayTermDesc | PayTermDesc.xsd |
| updateDetail | PayTermDesc | PayTermDesc | PayTermDesc.xsd |
This web service is used to expose pricing cost information to external systems. The primary user of this information is assumed to be an Order Management System (OMS), which manages franchise customer orders and needs visibility to cost information as part of the negotiation process for margin visibility.
Pricing cost for an item at an owned location is the unit cost for the primary supplier/country, less off invoice deals, plus estimated landed costs. Pricing cost for an item at a customer (franchise) location is the unit cost for the costing location, less any deals passed through, plus estimated landed costs (based on system option), plus the franchise cost template details. This API supports providing cost information for an item/location or item/supplier/location.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
Only Approved and transaction level items are valid.
Location must be company store or physical warehouse that is customer orderable. For a physical warehouse, it must also include the channel ID that should be used.
For physical warehouses, the cost returned will be for the virtual warehouse that matches channel ID included in the inputs. If there is not a virtual warehouse that matches that channel in the physical warehouse, then next best match will be determined based on channel type and the primary warehouse and protected flags on the virtual warehouses in the physical warehouse.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| lookup | PrcCostColCriVo | PrcCostColDesc | PrcCostCriVo.xsd
PrcCostColCriVo.xsd PrcCostDesc.xsd PrcCostColDesc.xsd |
/rms-PurchaseOrderManagement-AppServiceDecorator/ProxyService/PurchaseOrderManagementAppServiceProxy?wsdl
The Purchase Order Management service allows an external systems to request pre-issued order numbers, create a purchase order, modify a purchase order, or delete purchase order details.
The order reservation operation allows external systems such as Oracle Retail Assortment Planning (AP) to reserve order numbers in Merchandising to be used in orders that will later be created and integrated to Merchandising. This web service contains the following inputs:
| Column Name | Notes |
|---|---|
| Supplier Site ID | Optional - used it the requesting entity is a supplier |
| Quantity | Indicates the number of order numbers being requested. Required. |
| Days Until Expiry | Indicates how long the calling solution wants Merchandising to retain the reservation. After this many days, the reservation will be released allowing these numbers to be used for other purposes. This is required and must be a value greater than 0. |
The requested order numbers are sent back to the calling solution in the response. This operation is only available as part of the web service.
The operations supported in this service for creating and managing purchase orders are as follows:
Create a purchase order header and details
Modify purchase order header and details
Delete purchase order details
For the operations, this service uses the same logic as is used in the PO Subscription RIB API. For more information on the functionality, see PO Subscription API in the "RIB Subscription Designs" section of this document.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| preIssueOrderNumber | OrdNumCriVo | OrdNumColDesc | OrdNumCriVo.xsd
OrdNumDesc.xsd OrdNumColDesc.xsd |
| create | XOrderColDesc | InvocationSuccess | XOrderDesc.xsd
XOrderColDesc.xsd |
| modifyHeader | XOrderColDesc | InvocationSuccess | XOrderDesc.xsd
XOrderColDesc.xsd |
| createDetail | XOrderColDesc | InvocationSuccess | XOrderDesc.xsd
XOrderColDesc.xsd |
| modifyDetail | XOrderColDesc | InvocationSuccess | XOrderDesc.xsd
XOrderColDesc.xsd |
| deleteDetail | XOrderColRef | InvocationSuccess | XOrderRef.xsd
XOrderColRef.xsd |
/rms-ReportLocator-AppServiceDecorator/ProxyService/ReportLocatorAppServiceProxy?wsdl
This service is used by Oracle Retail Financial Integration (RFI) to retrieve the URL of a BI Publisher report from Merchandising or Sales Audit that can be invoked from the PeopleSoft Financials General Ledger based on a particular journal entry. The report URL that will be returned will be differ based on the ID sent in the service call. Based on that ID, Merchandising will determine if it was a Merchandising, Sales Audit, or Invoice Matching ID and return a URL for the appropriate report. Possible reports for Merchandising and Sales Audit are:
GL Fixed Deal Data Report
GL Item level Data Report
GL Item Rollup Daily Data Report
GL Item Rollup Monthly Data Report
GL Sales Audit Data Report
Also, for Invoice Matching, one of the following reports might be returned:
Merchandise Invoice Document Report
Non-Merchandise Invoice Document Report
Credit Note Document Report
Credit Memo Cost Document Report
Credit Memo Quantity Document Report
Debit Memo Cost Document Report
Debit Memo Quantity Document Report
Debit Memo VAT Document Report
Receipt Write Off Document Report
For cloud service implementations, this configuration should be done for you if you are configured to run with PeopleSoft Financials. For on premise implementations, you may need to configure this yourself in the RETAIL_SERVICE_REPORT_URL table. For cloud service implementations, coordinate this configuration with the Oracle Cloud Operations team.
The report is similar functionality to the Drill Forward and Drill Back functionality available in the Merchandising Transaction Data and Fixed Deal pages and the Sales Audit General Ledger Transaction page. See also Get Drill Back Forward URL Service for more on the APIs that support this functionality.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| publish | ReportLocDesc | ReportLocRef | ReportLocRef.xsd
ReportLocDesc.xsd |
This service is used by Oracle Retail Store Inventory Management (SIM) to create and manage store orders, as well as to query details to support these two operations.
The majority of the operations in this service are related to creating, updating, or deleting a store order. A store order is a request from the store for inventory that can result in either a purchase order or transfer being created in Merchandising.
The Create operation allows SIM to request the creation of an order for inventory from either a supplier or warehouse for one or more items. If the source of the inventory will be the supplier, then the order can be for more than one store. For warehouse sourced orders, it will be for a single store.
The Create Detail operation allows SIM to request the addition of an item to a previously created transfer or an item/location to a previously created purchase order.
Orders will be created in either Approved or Worksheet/Input status in Merchandising, depending on what is sent from SIM.
The Modify and Modify Detail operations allow SIM to update a previously created transfer or purchase order. For this type of update, SIM must send the status.
The Delete and Delete Detail operations allow SIM to request a delete of a previously created order or an order line item. If the order is in approved status and it is being sourced from a supplier, then the result will be a modification of the order to cancel the quantity or full order, rather than delete it. If it is not yet approved, then order details or order can be deleted.
This operation allows SIM to query Merchandising for the deals that an item/store, based on a specific date and source (supplier, partner). Merchandising will reply with details on the off-invoice deals that the item/location are part of based on the date provided. The details provided include the deal dates and discount details.
This operation allows SIM to query Merchandising for a specific item/location combination's sales data. Merchandising will respond by sending the available weeks of sales data, including the quantity sold, retail value, and sales type (for example, regular, promotion, clearance).
There are two operations that allow SIM to query store orders from Merchandising. Query Store Order accepts location and location type (store or warehouse), as well as optional filtering details like item, source (supplier site or physical warehouse), dates, and status. The operation returns a collection of header level details for the purchase orders or transfers that match the criteria, including the quantity on the order for the location.
The other operation, Query Store Order Details, accepts a specific order (purchase order or transfer), source type, and source and returns the details of that order, including the destination locations, status, dates, items, cost, and quantity.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| create | LocPOTsfDesc | LocPOTsfRef | LocPOTsfDesc.xsdLocPOTsfRef.xsd |
| createDetail | LocPOTsfDesc | InvocationSuccess | LocPOTsfDesc.xsd |
| modify | LocPOTsfDesc | InvocationSuccess | LocPOTsfDesc.xsd |
| modifyDetail | LocPOTsfDesc | InvocationSuccess | LocPOTsfDesc.xsd |
| delete | LocPOTsfDesc | InvocationSuccess | LocPOTsfDesc.xsd |
| deleteDetail | LocPOTsfDesc | InvocationSuccess | LocPOTsfDesc.xsd |
| queryDeal | LocPOTsfDealsCriVo | LocPOTsfDealsColDesc | LocPOTsfDealsCriVo.xsd
LocPOTsfDealsDesc.xsd LocPOTsfDealsColDesc.xsd |
| queryItemSales | LocPOTsfItmSlsCriVo | LocPOTsfItmSlsColDesc | LocPOTsfItmSlsCriVo.xsd
LocPOTsfItmSlsDesc.xsd LocPOTsfItmSlsColDesc.xsd |
| queryStoreOrder | LocPOTsfHdrCriVo | LocPOTsfHdrColDesc | LocPOTsfHdrCriVo.xsd
LocPOTsfHdrDesc.xsd LocPOTsfHdrColDesc.xsd |
| queryStoreOrderDetail | LocPOTsfDtlsCriVo | LocPOTsfDesc | LocPOTsfDtlsCriVo.xsdLocPOTsfDesc.xsd |
This service allows Merchandising to subscribe to supplier information from external financial applications. It is also used by Oracle Retail Financials Integration (RFI) for integrating supplier information into Merchandising from EBS, PeopleSoft, or Cloud Financials. The operations supported by this service are as follows:
Create a new parent supplier, including the associated sites, org unit, and address; it also supports adding flex attributes (CFAS) for supplier, supplier site, and address levels
Update an existing supplier, including adding or updating sites, org unit, address for the supplier, and flex attributes for the supplier, sites, and address levels
The operations supported by this service involve an external system sending Merchandising details to create or update suppliers or supplier sites. In the response back, the supplier or site IDs are returned on success. The create and update options for this service use the same logic as is supported in the Vendor Subscription RIB API.
For information about this functionality, see Vendor Subscription API in the "RIB Subscription Designs" chapter of this document.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| create | SupplierDesc | SupplierRef | SupplierRef.xsd
SupplierDesc.xsd |
| create | SupplierColDesc | SupplierColRef | SupplierColDesc.xsdSupplierColRef.xsd |
| update | SupplierDesc | SupplierDesc | SupplierDesc.xsd |
| update | SupplierColDesc | SupplierColDesc | SupplierColDesc.xsd |
/rms-TransferManagement-AppServiceDecorator/ProxyService/TransferManagementAppServiceProxy?wsdl
Merchandising exposes a Transfer Management service to allow an external application to create, update, and delete transfers. The web service takes in a collection of transfers and will return success and failure through the service response object. The operations supported in this service for creating and managing transfers are as follows:
Create a transfer header and details
Modify transfer header and details
Delete transfer header and details
For the operations, this service uses the same logic as is used in the Transfer Subscription RIB API. For more information on the functionality, see Transfer Subscription API in the "RIB Subscription Designs" chapter of this document.
Here are the filenames that correspond with each operation. Please consult the RSB documentation for each in order to get a detailed picture of the composition.
| Operation Name | Input Object Type | Output Object Type | XML Definition |
|---|---|---|---|
| create | XTsfColDesc | InvocationSuccess | XTsfDesc.xsd
XTsfColDesc.xsd |
| createDetail | XTsfColDesc | InvocationSuccess | XTsfDesc.xsd
XTsfColDesc.xsd |
| modifyHeader | XTsfColDesc | InvocationSuccess | XTsfDesc.xsd
XTsfColDesc.xsd |
| modifyDetail | XTsfColDesc | InvocationSuccess | XTsfDesc.xsd
XTsfColDesc.xsd |
| deleteHeader | XTsfColRef | InvocationSuccess | XTsfRef.xsd
XTsfColRef.xsd |
| deleteDetail | XTsfColRef | InvocationSuccess | XTsfRef.xsd
XTsfColRef.xsd |
This section gives an overview about the SOAP Web service Consumer Implementation API designs used in the Merchandising environment and various functional attributes used in the APIs.
The primary role of this service is to query customer address details related to a Sales Audit transaction. This may be required if you have configured Merchandising to not retain customer information (Retain Customer Information system options unchecked) for customer orders, but you wish to have visibility to it in Sales Audit when viewing/auditing transactions.
When Sales Audit calls this service, it will pass the customer ID and expect to receive back the following information in response:
First Name
Last Name
Company Name (if applicable)
Address Line 1
Address Line 2
Address Line 3
County
City
State
Country
Postal Code
Jurisdiction
Phone
Birthdate
As part of your implementation, if you have this system option configured off, you will need to provide a URL for Sales Audit to call. For on premise implementations, this will require updating the RETAIL_SERVICE_REPORT_URL table for code CAS. For cloud service implementations, configuration of this service call should be done in coordination with the Oracle Cloud Operations team by logging an SR.
The primary role of this service is for Merchandising to query customer/shipping details related to a customer order from an order management system (OMS). This is required if you have configured Merchandising to not retain customer information (Retain Customer Information system options unchecked) for customer orders and are sourcing customer orders from a warehouse or supplier where Merchandising needs to provide the address details for shipping to the customer.
When Merchandising calls this service, it will pass
Customer order number
Fulfillment order number
"Fulfillment location type and ID
Source location type and ID
And expect to receive back the following information in response:
Customer ID
Delivery Details
First Name
Phonetic First Name
Last Name
Phonetic Last Name
Preferred Name
Company Name
Address Line 1
Address Line 2
Address Line 3
County
City
State
Country
Postal Code
Jurisdiction
Phone
Billing Details
First Name
Phonetic First Name
Last Name
Phonetic Last Name
Preferred Name
Company Name
Address Line 1
Address Line 2
Address Line 3
County
City
State
Country
Postal Code
Jurisdiction
Phone
As part of your implementation, if you have this system option configured off, you will need to provide a URL for Merchandising to call. For on premise implementations, this will require updating the RETAIL_SERVICE_REPORT_URL table for code COA. For cloud service implementations, configuration of this service call should be done in coordination with the Oracle Cloud Operations team by logging an SR.
If you are implementing the Merchandising solutions with PeopleSoft Financials, then this service can be used allow users in Merchandising or Sales Audit to "drill forward" into Peoplesoft to view the General Ledger journal entries associated with a transaction or to "drill back" into Merchandising and Sales Audit from PeopleSoft General Ledger screens to view the source transactions associated with a journal entry. Both of these actions leverage this service call.
If you are configured use Merchandising with PeopleSoft Financials, then when you are in the following pages, you'll see Drill to Finance options that leverage this call:
Merchandising Transaction Data
Merchandising Fixed Deals
Sales Audit General Ledger Transactions
|
Note: Oracle Retail Invoice Matching also leverages this service for viewing transactions in PeopleSoft Payables. And Peoplesoft Payables can drill back to Invoice Matching as well. |
As part of your implementation, you will need to configure the URL for the service call in the RETAIL_SERVICE_REPORT_URL table for code RDF. For cloud service implementations, configuration of this service call should be done in coordination with the Oracle Cloud Operations team by logging an SR. For more information, see the RFI Implementation Guide.
When using Oracle Retail Financials Integration (RFI) to manage General Ledger integration an Oracle financial solution, a validation service is used to ensure that the segment combinations mapped to by Merchandising and Sales Audit users are valid combinations in the General Ledger. This validation is called from Merchandising and Sales Audit when creating General Ledger cross-reference mappings.
|
Note: This validation is also used by Oracle Retail Invoice Matching |
As part of your implementation, you will need to configure the URL for the service call in the RETAIL_SERVICE_REPORT_URL table for code RAV. For cloud service implementations, configuration of this service call should be done in coordination with the Oracle Cloud Operations team by logging an SR. For more information, see the RFI Implementation Guide.
